In barely two years, Sigstore has moved from academic curiosity to an assumed piece of the software supply chain. What makes the current moment interesting is not that the technology exists, which was already true in 2022, but that the registries where images actually live have finally accepted it as a first-class citizen. The tonal shift is what matters: until recently, signing an image was a political statement inside a team; today it looks more like enabling HTTPS on a fresh server, something you just do.
What changed in the last year
The tipping point cannot be pinned on a single release. It is the accumulation of signals. Kubernetes has been signing all of its images since 1.24, and that precedent has been copied across much of the CNCF ecosystem. PyPI published PEP 740 and is pushing Sigstore-backed attestations for Python packages. NPM added provenance in late 2023 on the same infrastructure. Homebrew started attaching provenance to its formulae. And Docker Hub, despite arriving late, now serves referenced artifacts in beta, the OCI mechanism where a Sigstore signature lives as a sidecar object associated with the image rather than contaminating its manifest.
Read together, signing has stopped being an exception and has become the default state that any mature pipeline is expected to produce, in the same way nobody argues anymore about generating an SBOM during the build.
Registry by registry
The registry best integrated with Sigstore remains GHCR. The reason is structural: GitHub Actions issues an OIDC token identifying the workflow, repository, and actor, and cosign sign --yes consumes it with no friction. The signature ends up bound to a verifiable identifier in Rekor’s transparency log without managing local keys or additional secrets. For open-source projects publishing to GHCR, adoption is already the majority.
Harbor has done its homework on the self-hosted side. Since version 2.5 it natively supports Sigstore signatures, allows enforcement policies per project, can point at private Fulcio and Rekor, and reflects signing state in the UI. For any organisation already running Harbor inside their network, adding verification is not a rewrite, it is a checkbox.
Quay (Red Hat) offers comparably mature support and integrates well with OpenShift. Google Artifact Registry fits naturally with Binary Authorization and accepts Sigstore-signed SLSA attestations, ideal when the whole stack already lives in GCP. AWS ECR is the awkward one: it supports Sigstore via OCI artifacts but has no UI or first-class integration, and AWS pushes its own KMS-based signing scheme. In practice this means AWS shops run both approaches side by side, and the choice is driven more by compliance than by technical preference. Docker Hub, finally, has the plumbing but not the UX: its search and repository view still do not know what to do with signatures.
Verifying without overbuilding
The interesting part is not signing, it is verifying in a way that turns the signature into a real gate instead of a decoration. There are three places where verification earns its keep: the cluster admission controller, the GitOps layer, and the CI/CD pipeline itself.
At the admission layer, Kyverno expresses a policy declaring the accepted identities (OIDC issuer plus a subject regex matching the organisation). When a Pod tries to start from an unsigned image, or one signed by an identity outside the policy, admission rejects it before the scheduler even sees it. Flux 2 offers the equivalent at the reconciliation layer: an ImagePolicy demanding cosign verification will block reconciliation if the signature does not match, giving you a second line of defence when the cluster has already accepted an image but the declarative pipeline has not yet approved the deploy.
In the pipeline the idea is simple: a pre-deploy step running cosign verify with specific identity-regexp and issuer arguments. The one command worth showing is the verification itself:
cosign verify "$IMAGE" \
--certificate-identity-regexp='^https://github.com/myorg/.+$' \
--certificate-oidc-issuer=https://token.actions.githubusercontent.comWhat matters is not the command but the contract behind it: only images produced by workflows inside our organisation pass. An attacker who uploaded an image signed by another identity would bounce at verification. An attacker who uploaded an unsigned image would bounce too. The command is almost incidental; the discipline is in having no deploy path that bypasses it.
Provenance, SBOM, and attestations
Signing the digest is level one. The next level, where the real action sits in 2024, is signing attestations about that digest: who built the image, with which builder, from which commit, which tests ran, which vulnerabilities the scanner found. cosign attest attaches those documents under the same identity model as the base signature, and the consumer can demand not only “is it signed” but “is it signed and does it carry a SLSA v1.0 provenance matching this repo”. Chainguard has pushed this model hard by publishing images with SBOMs attached by default, and Distroless does the same with Google-owned signatures.
Real limits worth acknowledging
Being rigorous means admitting what still limps. The public Rekor has rate limits that suffice for small projects but fall short for organisations with intensive builds: past a certain volume you need to stand up your own Rekor. Identity distribution is a governance problem: verification requires maintaining somewhere, versioned, which issuers and subjects are legitimate. Rotating CI identities (a repo ownership change, a migration between orgs) can break verification until policies are updated. And in regulated environments another debate weighs in: Sigstore keyless on public Fulcio is convenient, but many finance or healthcare teams prefer keys in AWS KMS, GCP KMS, or Vault because they fit their custody procedures better.
An honest recommendation for 2024
For an organisation starting today, the sensible path is to sign keyless with cosign from CI workflows, publish to GHCR or self-hosted Harbor depending on where the rest of the stack lives, enforce verification in admission with Kyverno, document accepted identities in the repository itself as versioned policy, and alert on unsigned images reaching production. There is no magic, no new product to buy, and the learning curve fits in an afternoon if the pipeline is already in reasonable shape.
What is worth internalising is that Sigstore does not solve supply chain security on its own: it solves the link “this image was produced by this process at this moment”. The full building, with SLSA L3, reproducible builds where feasible, policy as code, and observability of what reaches production, is still under construction. But the link that only recently was debatable is not debatable any more: signing OCI artifacts in 2024 is normal, and choosing not to is starting to require an explanation.
